Computer networking capabilities of a home personal computer (PC) are typically provided by telephone companies (Telcos) or commercial Internet Service Providers (ISPs) who operate network access points along the information superhighway. It is through these network access points that the user is able to connect with public domains, such as the Internet, and private domains, such as an intra-company computer network of the user's employer.
In the wholesale Internet access environment, the network access provider (NAP) and the network service provider (NSP) are not necessarily the same entity. Telcos and other wholesale ISPs are typical NAPs, who operate gateways (network access servers, access routers, or the like) in their points of presence (PoPs), and provide local loop access services to PCs. NSPs are typically the customers of NAPs, who are allowed to use the NAP's gateways to provide their Internet Protocol (IP)-based services, such as Internet access, network access, or voice over IP (VoIP) services to the PCs.
FIG. 1 illustrates Layer 2 Tunneling Protocol (L2TP). L2TP tunneling is a common service architecture for Point-to-Point Protocol (PPP) clients currently available at NAPs. In the typical L2TP tunneling environment, a PC 100 of a PPP client 105 starts a PPP session by dialing into a L2TP access concentrator (LAC) 110 located at the NAP's point of presence (PoP). The LAC 110 exchanges PPP messages with the client's PC 100 and communicates with a L2TP network server (LNS) 115 of a remote domain 120 such as an ISP or a private company. The LNS 115 is typically a home gateway (HGW) of the remote domain 120. The communication between the LAC 110 and the LNS 115 is by way of L2TP requests and responses. When a L2TP tunnel 125 is set up, the LAC 110 forwards the PPP session over the L2TP tunnel 125 to the LNS 115. Data packets in the PPP session are encapsulated into L2TP frames that are destined for the IP address of the LNS 115.
The LNS 115 is a termination point of the L2TP tunnel 125. The LNS 115 accepts L2TP frames, strips the L2TP encapsulation, and processes the incoming PPP frames for the appropriate interface. The PPP frames are processed and passed to higher layer protocols, i.e., the PPP session is terminated at the LNS 115. The PPP session termination requires and includes user authentication via a Remote Authentication Dial-In User Service (RADIUS) or other means. An authenticated PPP client then receives an IP address, a Domain Name System (DNS) address, and IP-based services that the client contracted. These are forwarded back to the client over the L2TP tunnel 125 through the LAC 110.
The L2TP passes protocol-level (or Data Link-level) packets through the virtual tunnel between the endpoints of a point-to-point connection, i.e., the client's PC 100 and the LNS 115. The L2TP is suitable for virtual private networking (VPN), in which users can dial into a NAP's network access server and join a private (typically corporate) network that is remote from the NAP's PoP.
FIG. 2 is a block diagram that illustrates a L2TP service architecture in which the NAP and NSP are different entities. Users A 200 and C 205 represent authorized users of a network at remote domain 210 and users B 215 and D 220 represent authorized users of a network at remote domain 225. A router may operate as both a LNS to given set of LACs and simultaneously as a LAC to a given LNS. When configured to operate in this way, the router is called a “multi-hop node” or “egress LAC”. In FIG. 2, NAP 230 provides network access to user C 205 and user D 220 and ingress LAC 235 tunnels PPP sessions via ingress tunnels 240 and 270 to egress LACs 245 and 265, respectively. NAP 250 provides network access to user A 200 and user B 215 and ingress LAC 255 tunnels PPP sessions via ingress tunnels 260 and 275 to egress LACs 265 and 245, respectively. Egress LAC 245 aggregates tunnels 240 and 275 into a single egress tunnel 280 to the LNS 285 at remote domain 210. Egress LAC 265 aggregates ingress tunnels 260 and 270 into a single egress tunnel 290 to the LNS 295 at remote domain 225. NSP 203 may also provide services for other remote domains (not shown in FIG. 2).
A typical service level agreement (SLA) specifies a minimum bandwidth to be provided during specified times of the day or week together with pricing information for the provision of such services. As shown in FIG. 2, NAP 250 and NAP 230 have separate SLAs 207, 213 with NSP 203. Additionally, NSP 203 has a third SLA 217 with remote domain 225 and a fourth SLA 223 with remote domain 210. However, sessions utilizing egress tunnel 290 are accorded the same level of service for the interface to LNS 295, and sessions utilizing egress tunnel 280 are accorded the same level of service for the interface to LNS 285.
NSPs typically aggregate a relatively high number of ingress tunnels from NAPs to a relatively low number of tunnels to a remote domain, and egress LACs are statically allocated to particular remote domains based upon expected network usage. As shown in FIG. 2, NSP 203 allocates a separate egress LAC for each remote domain. Egress LAC 265 is allocated for remote domain 295 and egress LAC 245 is allocated for remote domain 210. This static architecture allows for a limited increase in the number of subscribers using a particular egress LAC without reconfiguring the network. For example, if the subscribers using NAP 230 to access remote domain 210 increases beyond the capacity of egress LAC 245 to provide a minimum level of service, the network may have to be reconfigured by, for example, adding another egress LAC at NSP 203.
This approach has a number of drawbacks. First, placing all L2TP sessions for a particular remote domain on a single egress tunnel accords the same level of service to all sessions using that egress tunnel, regardless of any SLAs. Second, tying particular egress LACs to particular remote domains reduces scalability by requiring manual reconfiguration whenever an egress LAC becomes overutilized. Third, static configuration may allow some egress LACs to be underutilized while simultaneously allowing other egress LACs to be overutilized, resulting in a relatively inefficient utilization of resources.
What is needed is a solution that enables differentiated service for sessions using an egress tunnel. A further need exists for such a solution that minimizes the amount of network engineering required by NAPs and NSPs. Yet another need exists for such a solution that allows a service provider to share the same egress LAC across multiple remote domains while maintaining SLAs, providing relatively efficient utilization of resources.